Network users are able to access various types of information from the Internet and other sources. The type of information that the network users can access can be broadly divided into two categories: realtime streams and non-realtime streams. For example, a typical user will be receiving realtime data streams of video or audio and non-realtime data streams like e-mail, web pages, or File-Transfer Protocol (FTP) downloads. Realtime data-streams are generally required to be transmitted or processed within some small upper limit of time. Non-realtime data-streams are broadly understood to be not requiring processing or transmission within the time constraints such as those required for the realtime data-streams. Realtime and non-realtime data-streams have differing characteristics as described next.
The chief characteristics of realtime and non-realtime data-streams of relevance here are their respective bandwidth requirements for providing different levels of Quality-of-service (QoS). QoS is broadly understood as the set of performance properties of given a network service, generally including throughput, transit, delay and priority. In the present context of realtime streams, the additional QoS parameters include bandwidth availability, delay and jitter among other parameters. Those skilled in the art will appreciate that relevancy and importance of any given QoS parameters will depend upon the nature of the realtime data stream used in a particular application. The invention covers and supports any set of QoS parameters for a given realtime data stream. Realtime streams need a guaranteed QoS for providing relatively fast and time constrained information transmission. Non-realtime streams are generally transmitted using the transmission control protocol (TCP)/Internet Protocol (IP). Contrastingly, non-realtime streams do not generally require the QoS similar to that required for the realtime streams. A typical example of a network handling realtime and non-realtime data-streams is described next.
A network can be configured to receive both realtime and non-realtime data-streams from an external source. A single transmission channel generally links the user's network to the Internet service provider (ISP). The same transmission channel concurrently carries both the realtime and non-realtime streams. The bandwidth capacity of such a transmission channel generally remains fixed. Therefore, it becomes necessary to balance the allocation of available bandwidth between the conflicting demands made by the realtime and non-realtime streams. The problem of bandwidth allocation is illustrated next in the context of a typical user.
A network user is usually connected to a network like Internet through a service provider who may provide Internet-access and possibly other services like video-on-demand, IP telephony, streaming audio and video. The service provider is linked to the network user by a transmission channel like a dial-up telephone line, xDSL, ISDN, etc. The connecting device at the service provider's end may be an edge router, and at the network user end it would generally be a gateway.
Realtime data-streams require an almost fixed allocation of bandwidth. Realtime data-streams offer little flexibility in adjusting bandwidth requirements without compromising the QoS parameters. In contrast, the non-realtime data-streams are relatively flexible about their bandwidth demands, because they do not usually require a relatively strict QoS. Bandwidth availability may change over a given period of time. Therefore, the non-realtime stream traffic from the service provider to the network user needs to be controlled in order to ensure that the realtime streams get the required bandwidth for maintaining its QoS. Possible methods for controlling the sharing of bandwidths are considered next.
A conventional approach using a packet pacing method is discussed next. Non-realtime traffic transmitted from the router located at the service provider to the gateway will generally be the Internet communication traffic transmitted using the TCP protocol. The TCP sender at the Internet site controls the non-realtime traffic by pacing the non-realtime packets to ensure that the realtime traffic gets the required bandwidth. The packet pacing method and its associated problems are described next.
Packet pacing is generally performed by controlling the rate of packet transmission. Implementing such packet pacing method requires significant changes in the operations of a TCP sender. In a typical network user scenario the TCP sender, i.e., a HTTP server, is under control of an external agency like a university, hospital, or company. The ISP may not be expected to employ any particular bandwidth management techniques. An ISP typically will be servicing a large number of users in a situation where each one of the users has several active TCP connections operating at the same time. Such packet pacing approach is not feasible to implement at an ISP site due to scalability problems associated with supporting a large number of users. Thus, there is a need for an improved bandwidth management technique that is implemented at the gateway side of the network.
Another approach involves controlling the TCP traffic for the non-realtime streams from a conventional user gateway. The difficulty with this approach is that the TCP-receiver at the user gateway has almost no operatively effective control over the TCP-sender, which is typically a Hypertext Transfer Protocol (HTTP) server or a FTP server. Hence, there is a need for an apparatus and method that allows controlling the non-real time traffic at the gateway end, and which is feasible in a TCP environment without using any special apparatus at the user end.
Above described known methods for bandwidth management in networks where realtime and non-realtime traffic share the available bandwidth of a channel have several drawbacks as described above. Thus, there is a need for a bandwidth management solution that allows controlling the non-realtime streams bandwidth demands so that the realtime streams can provide a desired QoS. Further, there is a need for implementing such a solution on the gateway located at the user's end of the network.